1. Field of the Invention
The present invention is generally in the field of debuggers for processors and, more particularly, in the field of debugging multiprocessor systems.
2. Background Art
Software for embedded systems is conventionally developed using a single micro controller or a digital signal processor (DSP) and either an emulation or simulation module to which a debugger is attached. A debugger is a tool that aids a programmer or developer in locating and correcting errors in the system. In the case of a simulation module, the debugging system and the debugger are both implemented in software.
When debugging software in a multiprocessor environment using multiple debuggers, the state of each individual processor is displayed independently in each debugger. However, multiprocessor systems typically share system resources such as shared memory. When a user changes the state of a “shared system resource,” by utilizing a debugger, the other debuggers are not informed of the change to the system state. Furthermore, many multiprocessor systems now exist which contain a centralized control structure to allow the execution state of all the processors in the system to be started and stopped synchronously. This is true of most system simulation environments that utilize a centralized clocking scheme and a centralized debug controller. In these environments, any of the attached software debuggers can modify the execution state of all of the processors. When this modification occurs, the other debuggers are no longer coordinated with the system to which they are attached.
In the past, hardware/software developers typically limited themselves to debugging one processor at a time to limit the source of state changes in the system. When the need to simultaneously debug multiple processors arose, the hardware/software developers were forced to manually re-synchronize the debuggers. An alternative approach was to create a single debugger capable of debugging multiple processors. In this environment all state changes come from a single source. Unfortunately, this type of debugger is more difficult to develop and must be modified if a new type of processor is added to the environment.
FIG. 1 illustrates a conventional exemplary single-processor system simulation, i.e. debugging system 100. In the present application, the entity upon which a debugger acts will be referred to as a “target” within a “system simulation.” A system simulation may include, for example, several targets, a scheduler, and a shared system resource such as a shared memory. Furthermore, a target may contain a central processing unit (CPU), among other elements. As shown in FIG. 1, debugging system 100 includes a debugger, i.e. debugger 110, which communicates with a processor model, i.e. system simulation 120. Debugger 110 is used to control and display the state of system simulation 120.
Many of today's embedded software applications are complex and cannot be properly supported by a single microprocessor system. FIG. 2 illustrates an exemplary conventional multiprocessor system simulation, i.e. debugging system 200. Debugging system 200 includes debuggers 210, 212, and 214, a shared system resource such as shared memory 228, and targets 220, 222, and 224. Targets 220, 222, and 224 further comprise CPUs 221, 223, and 225, respectively. Information, e.g. a “stop command,” can be communicated from debuggers 210, 212, and 214 to targets 220, 222, and 224, respectively, as represented pictorially by “communication lines” 216, 217, and 218, respectively. Furthermore, shared memory 228 can have two-way communication with targets 220, 222, and 224, as represented pictorially by two-way “communication lines” 230, 232, and 234, respectively. As an example, debugger 210 may issue a command to CPU 221 in target 220, via communication line 216. A problem that arises in conventional multiprocessor debugging systems, such as debugging system 200, is that the debuggers are not aware of changes made to the system state by other debuggers. This problem can be illustrated by the following example.
As mentioned above, debugging system 200 includes three CPUs: CPU 221, CPU 223, and CPU 225, which are run in debug mode using debugger 210, debugger 212, and debugger 214, respectively. Moreover, CPUs 221, 223, and 225 may share system resources, such as shared memory 228. Thus, debugger 210 may issue a command to CPU 221 which will in turn cause a change in the state of shared memory 228 within system simulation 250. When debugger 210 changes the state of shared memory 228, debugger 212 and debugger 214 are not informed of this change and are thus not updated to reflect the current state of shared memory 228. In effect, each debugger in debugging system 200 acts as if it is the only entity that may change the state of a shared system resource, and that its commands are necessarily executed, without accounting for the actions of other debuggers. Due to this lack of coordination between the debuggers and the system simulation, debuggers 212 and 214 may initiate improper commands, or may fail to initiate necessary commands.
Thus there is a need in the art for coordination of multiple debuggers in a multiprocessor simulation environment.